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Glossary of Terms 


ADQIT 


API 
BERP 
FLAP 
GDS 
imode_proxy 
L21P 
PCL 
PF 
QC 
QMI 
QR 
QRR 
SAPI 
SNAC 
SOML 
SUS 
Tcl 
TSEC 


TWeb 
Ul 

VR 
WERP 


Asynchronous Data Query Interface Thing (a communications protocol for talking 
to GDS) 


Application Programming Interface 
Back-end Routing Processor 

Frame Layer Protocol 

Generic Data Station (also known as File Station and Form Station) 
A server that acts as the DoCoMo agent. 
Layer Two Tunneling Protocol 
Preemptive Command Language 
Personal Finance 

Queue Context 

Queue Message Interface 

Quote Request 

Quote Request Reply 

Server API 

Simple Network Atomic Communication 
Son of MainLoop 

System Update Server 

Tool Command Language 


Secunity server that updates/verifies the certson the client and sets the time on 
the AOLTV servers. 


TurboWeb 

User Interface 

View Rule 

Web-End Routing Processor 
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1 Introduction 


1.1 


WERP is an acronym for the Web-End Routing Process, a routing process for HTTP 
requests. WERP is a process to provide initial parsing for HTTP requests, the routing of 
the request amongst various other processes, and the formatting of the HTTP response 
to the client browser. 


From the client perspective, for example, AOLTV, WERP functions as Web server. 
From the host infrastructure perspective, WERP manages web services by 
communicating with the following resources: 


Provides communication to the WERP from the client by way of the 
TurboWeb L2TP tunnel. After processing the request, WERP sends the requested 
subsystem page back to the client through the same path. 


Provides repository of scripts used by the script processors to develop 
dynamic content pages. When WERP receives a client request by way 

Data station of the TurboWeb (TWeb) subsystem, WERP parses the request and 
retrieves the appropriate script from the data station. 


Builds dynamic web pages based on requests received from WERP. 
The dynamic web pages are based on scripts and additional templates 


ee pad from the data station sent by way of WERP and data from existing 
P services sent by way of WERP and BERP. 
BERP Provides access to existing services to retrieve data needed for the 


script processors to build dynamic web pages. 


GDS 


GDS, known as the Data or File Station, stores a variety of files. GDS stores forms, art, 
and and other things. For purposes of WERP it stores script sets. A script set is 
identified by aname. A script set is composed of one or more subsets identified by a 
view rule. The view rules of the subsets are evaluated in order until a subset is found 
whose view rule returns true. Each of these subsets is then further divided into one or 
more scripts, each identified by a text language. WERP communicates with GDS using 
the ADQIT API which sends and receives QMI messages. Each WERP needs a direct 
link to the GDS servers that it uses. A GDS setup usually has replicated servers and 
multiple sites. 
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1.2 


1.3 


Script processors 


Scripts that are processed through the WERP may contain logic to control the output. 
Additionally, they may contain commands that include additional scripts or send and 
receive messages to and from back-end servers. 


Two general user script processors are available: 
e PCL 
e AOLserver 


WERP supports special-purpose processors. Such processors need not interpret 
commands in the script; they can by specific to function such as a security server. It is 
also possible that a script may be "self-contained"; that is, it contains the complete 
content that is to be delivered to the member. In this case, WERP bypasses sending it 
through a script processor and sends it directly to the member. 


Scripts have a number of attributes associated with them. Two of the important ones are: 
e Function—identifies the functional area to which the script applies. Functional 
areas are things such as Quotes and Portfolios and Screen Name Administration. 
e Script Language—identifies the scripting language used by the commands 
within the script. 


The attributes are taken together, or script language is taken alone by the WERP to 
identify a class of script processors. 


The use of "function" in the selection allows us to configure general-purpose script 
processors for specific functions. This could be needed to load certain command 
procedures used for the function, or might be done to manage CPU and memory 
utilization. 


For each script processor class, one or more script processor connections are defined. 
WERP communicates with the script processor using FLAP over TCP/IP. 


AOL Back-end Servers 


Scripts contain text and markup tags needed to format a page on the member's browser. 

A script may need access to variable information during construction of the page. Such 
information might consist of stock quotes, or parental control settings for a given screen 
name, etc. 


Since this information is typically available from existing AOL back-end servers, WERP 
provides a means for script processors running scripts to build and send messages, 
through the WERP, to these back-end servers and for the response to be returned. 


All requests and responses between script processors and back-end servers are done in 
SNAC format. Between WERP and back-end servers, QMI messages are forwarded 
through the BERP or sent directly to the back-end server. WERP supports either 
configuration. 
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1.4 


1.5 


1.6 


1.7 


Forward Messaging 


To talk to back end server with forward messaging you need qc (queue context). WERP 
gets the qc from the x-aol header normally. You can not do a berp forwarded message if 
you do not have qc. If you did not have qc you would have to have direct links from the 
werp to the back end servers if you wished to perform such requests. 


Document Conventions 


The following conventions are used throughout this document: 

















Type Font/Syntax 
Narrative text Font as shown 
Scripts, code, names of variables, Font monospaced; for example, 
procedures, and commands New Courier 








Intended Audience 


This documentation is written for systems, script, and client developers and others who 
need to understand the functions of the werp. 


More Information 


For more information on PCL, see: 

e PCL Tutorial and Quick Reference, Rel. 1.1 the sdtechdocs web site 
(Keyword:techdocs or https://sdtechdocs.web.aol.com/library/index. html) 

e Listserv for PCL developers at scriptdev @listserv.sup.aol.com. To subscribe, 
send an email to listserv @listserv.sup.aol.com with the following in the email 
subject line and again in the body: "subscribe scriptdev John Smith". Obviously, 
substitute your name for John Smith. 

PCL section of Infrastructure Fag-O-Matic 

Sample PCL scripts with the werp-control-port command 
werp_show_scripts, get access to AOL test machines and Telnet to the 
werp's control port (39450) on twerp01.test.aol.com and (54509) 
twerp03.test.aol.com 

e ‘help pel’ on PCL control ports twerp01.test.aol.com 39451 
twerp03.test.aol.com 54504 














For more information on AOLserver commands and scripts, see: 
e AOLserver documentation http://aolserver.com/ 


For more information on AOLTY, see: 
e AOLTV documentation at the sdtechdocs web site (Keyword:techdocs or 
https://sdtechdocs.web.aol.com/library/index.html 





For more information on BERP, see: 
e BERP documentation at the sdtechdocs web site (Keyword:techdocs or 
https://sdtechdocs.web.aol.com/library/index.html 
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2 WERP Event Flows 


WERP supports a wide variety of different paths to facilitate the multifarious functions 
of clients like Personal Finance, AOLTV, and DoCoMo. Some scripts are PCL, others 
TSEC, others connect directly to the client, while still others go to the back-end servers. 


The following WERP event flows are described: 
Script Without Script Processor 

Simple Script Processor Script 

PCL Script Including Another PCL Script 
PCL Script With Outbound HTTP Call 
PCL Script With Call to Back-end Server 


2.1 Script Without Script Processor 


Figure | describes the event flow for a script where data is returned to the client without 
a script processor. 
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Figure 1. No Script Processor Event Flow 


The event flow steps are as follows: 
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2.2 
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An HTTP request is sent from the client browser to the Spider. 


The request is received by the WERP. WERP parses the HTTP request. The URI in 
the request line is split into the base form and query parameters. The base part of the 
URI is used as a script set key. If the script set is in the cache, that setis used. 


If the script set is not in cache, the set is requested from the GDS. 


. WERP selects the specific script from that set using view rules and language 


preferences. A script processor class is selected using the function and/or script 
language attibutes of the script. If the selected script processor class is "- 
self_contained," the script is used as the response to the member and processing of 
the HTTP request is complete. 


5. WERP returns the response to the Spider. 


If the request is for a standard image (for example, *.jpeg), the image is returned 
directly to the browser. 


Simple Script Processor Script 


Figure 2 describes the event flow for atypical script using a processor (for example, 
PCL, TSEC, or SUS. 
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Figure 2. Script Processor Event Flow 
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2.3 


The event flow steps through the WERP, proceeds as follows: 
1. An HTTP request is sent from the client browser to the Spider. 


2. The request is received by the WERP. WERP parses the HTTP request. The URI in 
the request line is split into the base form and query parameters. The base part of the 
URI is used as a script set key. If the script set is in the cache, that setis used. 


3. Ifthe script set is not in cache, the set is requested from the GDS. 


4. WERP selects the specific script from that set using view rules and language 
preferences. A script processor class is selected using the function and/or script 
language attibutes of the script. If the member has not been assigned to a specific script 
processor connection, one is selected and recorded for the user. 


5. The parsed HTTP request and the script are sent to the PCL, TSEC, SUS or other 
script processor. 


6. When the script processor completes the script, it returns the reply to WERP. 
7. WERP formats an HTTP response and send it back to the spider. 


8. The spider sends the response back to the client. 


PCL Script Including Another PCL Script 


Figure 3 describes the event flow for atypical script using a processor (for example, 
PCL, TSEC, or SUS) that includes another script. 
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Figure 3. Script Processor Including Another Script Event Flow 


The event flow steps through the WERP, proceeds as follows: 


tt) 
2: 


An HTTP request is sent from the client browser to the Spider. 


The request is received by the WERP. WERP parses the HTTP request. The URI in 
the request line is split into the base form and query parameters. The base part of the 
URI is used as a script set key. If the script set is in the cache, that setis used. 


If the script set is not in cache, the set is requested from the GDS. 


WERP selects the specific script from that set using view rules and language 
preferences. A script processor class is selected using the function and/or script 
language attibutes of the script. If the member has not been assigned to a specific 
script processor connection, one is selected and recorded for the user. 


The parsed HTTP request and the script are sent to the PCL, TSEC, SUS or other 
script processor. 


Also during processing of the script, the script processor might include additional 
"template" scripts. For example, the script processor sends a "template" request to 
WERP. This "template" is actually a script set name, so WERP goes through its 
normal script set and script selection logic. 
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7. The selected script is returned to the script processor. The function and script 
language logic is skipped for templates; the script is returned to the requesting script 
processor. 


8. When the script processor completes the script, it returns the reply to WERP. 
9. WERP formats an HTTP response and send it back to the spider. 
10. The spider sends the response back to the client. 


2.4 PCL Script With Outbound HTTP Call 


Figure 3 describes the event flow for atypical script using a processor (for example, 
PCL, TSEC, or SUS) that includes another script. 
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Figure 3. Script Processor Including Outbound HTTP Call 
The event flow steps through the WERP, proceeds as follows: 
1. An HTTP request is sent from the client browser to the Spider. 


2. The request is received by the WERP. WERP parses the HTTP request. The URI in 
the request line is split into the base form and query parameters. The base part of the 
URI is used as a script set key. If the script set is in the cache, that set is used. 


3. Ifthe script set is not in cache, the set is requested from the GDS. 
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2.5 


4. WERP selects the specific script from that set using view rules and language 
preferences. A script processor class is selected using the function and/or script 
language attibutes of the script. If the member has not been assigned to a specific 
script processor connection, one is selected and recorded for the user. 


5. The parsed HTTP request and the script are sent to the PCL, TSEC, SUS or other 
script processor. 


6. During processing of the script, the script processor might need to make an http 
request to an outbound server. The processor sends a request to WERP. 


7. WERP sends the request to Spider. 
Spider calls the requested server. 
9. Spider receives the returned data. 
10. Spider sends the returned data to WERP. 
11. WERP sends the requested information back to the script processor. 
12. When the script processor completes the script, it returns the reply to WERP. 
13. WERP formats an HTTP response and send it back to the spider. 
14. The spider sends the response back to the client. 


PCL Script With Call to Back-end Server 


The event flow for a PCL script that call to a back-end server is shown in Figure 5: 
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The event flow steps through the WERP, proceeds as follows: 
1. An HTTP request is sent from the client browser to the Spider. 


2. The request is received by the WERP. WERP parses the HTTP request. The URI in 
the request line is split into the base form and query parameters. The base part of the 
URI is used as a script set key. If the script set is in the cache, that set is used. 


3. If the script set is not in cache, the set is requested from the GDS. 


4. WERP selects the specific script from that set using view rules and language 
preferences. A script processor class is selected using the function and/or script 
language attibutes of the script. If the member has not been assigned to a specific script 
processor connection, one is selected and recorded for the user. 


5. The parsed HTTP request and the script are sent to PCL (or other script processor). 


a. During processing of the script, the script processor might need information 
from an AOL back-end server. The script processor builds the request to the back- 
end and sends it to WERP. 


b.WERP looks at the SNAC foodgroup, foodgroup version, and SNAC type in the 
request and selects a back-end queue name to send the SNAC to. 


c. If the queue selected is for a berp forwarded message, berp forwards the SNAC 
message to the back-end server. If the message is fora directly linked, or round robin 
server then it is sent directly there. 


10 


March 2001 Overview of WERP Functionality 


d. The back-end server forwards the reply back to berp. 

e. berp sends the reply back to the WERP. 

originating script processor. 
6. WERP routes the reply. 

a. WERP sends the reply back to the originating script processor. 

b. When the script processor completes the script, it returns the reply to WERP. 
7. WERP formats an HTTP response and send it back to the spider. 


8. The spider sends the response back to the client. 


3 Configuration 


3.1 Control Port Commands 


werp_info Displays the version information, configuration 
parameters, and control port commands for WERP. 

http_info Displays version, configuration parameters, and 
commands for HTTP_subs. HTTP_ _subs is used by 
WERP to parse HTTP requests and build responses. 

fsm_info Shows version and commands the FSM_subs (Finite 
State Machine subs). This library is used by WERP for 
FLAP connection state management with the script 
processors. 


Interface Thing (ADQIT) that is being used. 

snac_load_protocol werp.cud Loads the SNAC foodgroup and type protocol 
definitions. WERP uses the werp.cud file to define the 
SNACs for script sets and communicating with the 
script processors. It also uses the file to define SNAC 
foodgroups and types for SNAC messages sent from 
script processors to AOL back-end servers. This 
command is normally placed in the werp_post.tcl file to 
load the protocol at startup, but it can also be used from 
the control port to dynamically reload the SNAC 
protocols. 


werp_show_cache [<script- 
name-list>] 


werp_show_script_sets 
<script-—name-list> 
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werp_show_scripts -—set 
<script-name-list> 
[view_rule <view-rule 
list> ] 
[-language <language- 
list> ] 

















3.2 HTTP Listen Address Configuration 


WERP is built using HTTP_subs. This library provides several tunable parameters and 
control port commands. WERP also uses the dynamic DNS library to resolve host names 
and it provides several commands. 


3.3 Configuration and Tunable Parameters 
Command/Parameter 


HTTP_KEEP_ALIVES_OFF Controls whether or not connection keep- 
alive logic is honored. 









































ase [| SCS 
joass76 | SSCS 
T 


TP_SSSL_DRAIN_TIMEOUT 30 Parameter give the maximum size, in bytes, 
of HTTP requests or responses. 





























init only) | when closing connections. 
dns_nameserver <nameserver— Flag to control SSSL using SST (1) or TC 
+ deep eS (0). Gives the IP address of a DNS name 
server. Multiple commands may be given to 
define the name servers. This command 
must precede and other WERP commands 
that contain host names. 
Adds an HTTP listen address for the 
specified host interface device and port. See 
Technical Note below. 


Deletes a specific HTTP listen address. 


name> <port> 
Displays the currently-defined HTTP listen 


werp_show_http_addr 
addresses. 


http_re2_key <"re2-key"> Gives the RC2 key used to decrypt QC and 





werp_add_http_addr <host- 
name> <port> [-sst] [-ssl] 


werp_del_http_addr <host- 


DM fields in the X-AOL header. Multiple 


keys may be given, HTTP_subs remembers 
the last four that have been defined. 


http_show_headers [<header- 
pattern>] 


HTTP is an ASCII-based protocol, which 
means that it is too easy for everybody to 
generate HTTP requests. In other words, 
HTTP_subs has to be prepared to get all 
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kinds of ridiculous requests. To assist in 
making HTTP_subs more efficient, it 
records the last five improperly constructed 


headers of each name in a circular, in- 
memory buffer. This command is used to 
display that buffer. 





Technical Note: Multiple commands may be used to specify multiple listen addresses. 
The -sst flag is not functional at this time; in the future it will cause the TCP/IP traffic to 
be processed by SST. (At present, this is controlled by the HTTP_USE_SST 
configuration parameter.) The -ssl flag indicates that the connection is used for HTTPS 
(secure connections). When defining listen addresses, "localhost" can be used for the 
<host-name> value. With non-SST, it equates to 0.0.0.0 as no local address is needed. 
With SST, WERP gets a random address for the proper interface using the SST 
configuration parameters. 


3.4 File Station Configuration 


Gives the maximum time that WERP waits 
for responses from the Data Station. 
0 (pre- 
1048576 | 
Fa 


a 



































0 
0 (pre- 
init only) 


a 
SSS SS 
a 
































3 




















R 
PI 
ER 
R 
R 











WERP_CSC_USE_ADOIT_MS 








3.5 Configuration Parameters for ADQIT Interface 


Issue: 


config { var_info WERP_CSC* } 





for more detail. 


Parameter 
Show the currently defined Data Station class(es). 


werp_cscf_load_config <file- Command used for Data Station configuration and is 
aes typically given only in the werp_port.tcl file. 


werp_cscf_reload_config Command used for Data Station configuration. 
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werp_cscf_show_config Same comment as above 


werp_cscf_locate <script-set— | Same comment as above. 

name> 

werp_csc_station_stats Command used to show performance stats for the link 
to Data Station configuration. 


werp_csc_station_hist 
werp_csc_stats 


werp_csc_routing 
[hashed|round_robin] 
ferpesesero CEOS 








3.6 Script Processor Configuration 


The following parameters and commands control communication between WERP and 
script processors. 


Default 


ERP_F'G_VE Gives the foodgroup version for WERP 
SNACs that originate from WERP and are 
sent to script processors. Replies sent to 
SNACs originating with the script 
processors are always sent in the same 
version as the request. 


9 Controls open and re-open attempts for 
connections from WERP to script 
processors. If/when a connection closes, 
WERP makes 
WERP_REOPEN_ATTEMPTS_FAST 
attempts to re-establish the connection 
waiting 
WERP_REOPEN_TIME_LIMIT_FAST 
seconds between each try. After that, it 
does (WERP_REOPEN_ATTEMPTS - 
WERP_REOPEN_ _ATTEMPTS_FAST) 

/60 











AAP_SIGNON_TIME 





























more attempts waiting 
WERP_REOPEN_TIME_LIMIT between 
each. If the connection still cannot be 
established, it is put in a stopped state. 
Same comment as above. 
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complete processing of a script and 
send a reply back. If this time limit is 
exceeded, WERP sends a 408 Request 
Timeout back to the member. 
werp_add_func_lang <function> Defines a function/script-language mapping 
SPeNGUAIeS SOLAS ec |S to a script processor class. Alternatively, the 
self_contained} : : 
special name of -self_contained may be 
used to indicate that the script is to be 
returned to the member directly without 
going through a script processor. A set of 
these commands is normally placed in a 
separate file that is sourced from the 
werp_post.tcl file. The file should also 
contain the werp_add_class commands. An 
updated version of the file can be sourced at 
any time from the control port. A 
werp_add_func_lang for existing mappings 
is ignored. If a new script processor class is 
given for an existing function/script- 
language, the class is updated. Entries not 
in the new file are kept and must be 
removed with werp_del_func_lang. 


werp_del_func_lang <function> Deletes a function/script-language mapping. 
<language> 


werp_show_func_lang [-func] Displays the currently-defined 

iebaetd function/script-language to class mappings 
if -func is given (or assumed by default). If 
-hist is included, a histogram of how long 
processing has taken for scripts sent to each 
class is displayed. 

Werpsadd chase. <chass2 A) Defines a class of script processors One or 

ee more werp_conn commands mus be 

rule>] es included to define the connections to 

autostart |—-no_auto_start] instances of that script processor. A set of 
these commands is normally placed in a 

} separate file that is sourced from the 

werp_post.tcl file. The file should also 
contain the werp_add_func_lang commands. 
An updated version of the file can be 
sourced at any time from the control port. A 
werp_add_class for existing classes are 
valid as long as none of the embedded 
werp_conn commands alter the state of any 
connections that are not in the stopped state. 
New connections can be created 
dynamically by simply adding new 
werp_conn commands to the affected 
werp_add_class entries. If a given 
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connection is not defined in the new 
werp_add_class entry, the corresponding 
connection is deleted. However, that 
connection must be in the stopped state for 
this to happen. However, if an existing class 
is not included in the new file, that class is 
retained until removed with a 
werp_del_class command. On the 
werp_conn command, <conn-id> must be a 
unique number for each connection within a 
class. <host> and <port> identify how to 
reach the script processor. -vr <view-rule> 
can be used to restrict the connection to 
members that pass the given view rule. - 
auto_start and -no_auto_start control 
whether or not WERP attempts to start the 
connection after the config entry is loaded. 
Deletes a script processor class. Before a 
class can be removed, all connections 
defined within it must be in a stopped state. 


werp_del_class <class> 


werp_show_conn [ {<class>|*} 
[ {<conn-id>|*} ] ] [-trans 
[<n>] ] 

[-hist] [-req] [-sess] [ 
conn] [-delta] [-reset] 
werp_start_conn {<class>|*} 
{<conn-id>|*} [-dns] 


Displays information about the script 
processor connections. See Technical Note 
A below. 





Starts one or more connections to script 
processors. Giving * for a connection ID 
causes all connections for the class to be 
started. Putting * for the class means start 
all classes. If a connection is in a state other 
than stopped or reopen delay, the command 
has no effect. Stopped connections go to the 
opening or DNS pending state while ones in 
reopen delay go immediately to the opening 
state (not passing Go and not collecting 200 


werp_stop_conn {<class>|*} 
{<conn-id>|*} [-quiesce] [- 
abort] 


Stops one or more connections to script 
processor classes. See Technical Note B 


werp_show_class Displays the currently defined script 
processor classes and connections. 





Technical Note A: If no arguments are given, or a single *, the current state of each 
connection for all classes is shown. Specifying a class causes only the state of the 
connections for that class to be displayed. If a specific class (or *) and connection (or *) 
is given, detailed stats are shown for each connection. When using both the class and 
connection specifier, additional flags can be given: 
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* -—trans [<n>] causes the last <n> (default 50) state transitions to be displayed. 





* -hist, -req, -sess, -conn, -—delta, -—reset cause a histogram of 
response time for requests processed by the specific instances of the script processors to 
be shown. By default, the histogram includes requests, sessions (how long a member 
makes use of a script processor), and connections are displayed. The -req, -sess, and - 
conn flags can be used to select one or more specific histograms. Using -delta shows 
changes only from the last time -reset was used while -reset causes the values to be 
reset after they are displayed. 


Technical Note B: The action taken by this command depends upon the state of each 
connection. Connections in the DNS pending, opening, or reopen wait states are 
stopped. For opened connections, the action further depends upon the flags that are 
used and whether or not the connection has any members assigned to it. No users and 
no flags or -quiesce given (-quiesce is default). FLAP close is issued and connection 
will go to the stopped state. Active users and -queisce is given or assumed: connection 
changes to the quiescing state. Active users OR no active users and -abort is given: 
connection is aborted and will convert to stopped. Stops one or more connections to 
script processor classes. The action taken by this command depends upon the state of 
each connection. Connections in the DNS pending, opening, or reopen wait states are 
stopped. For opened connections, the action further depends upon the flags that are used 
and whether or not the connection has any members assigned to it. No users and no 
flags or -quiesce given (-quiesce is default): FLAP close is issued and connection will 
go to the stopped state. Active users and -queisce is given or assumed: connection 
changes to the quiescing state. Active users OR no active users and -abort is given: 
connection is aborted and will convert to stopped. 


WERP uses FSM_subs to manage the FLAP connections to script processors. This is a 
general-purpose finite state machine library that defines some additional control port 
commands. 


Parameter Comment 


fsm_states Lists the defined states. Valid states for WERP 
connections are: 


Initial—Just defined with werp_conn. 
DNS Pending—Waiting for response from DNS. 


Opening—Trying to open connection to script 
processor. 


Opened—Connection established with script 
processor. 


Reopen Wait—Waiting to retry connection attempt. 


Closing—Waiting for script processor to complete 
normal close. The connection will then immediately 
go into reopen wait state and a new connection will 
be attempted. 
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e Stopping—Waiting for script processor to complete 
normal close. The connection will then go to the 
stopped state. 


Quiescing—Waiting for members assigned to the 
script processor connection to log out. No new 
members will be assigned to the connection. When 
the last member logs out, the connection will change 
to the stopping state until it is closed, then will go to 
the stopped state. 


Stopped—Connection was manually stopped, never 
started after being defined (-no_auto_start), or had 
some non-transient error. Manual intervention is 
required to get out of this state. 
fsm_events Shows the defined events. For WERP connections, 
these events are: 


e Issue DNS Query—DNS name resolution is being 
requested. 


Go Stopped— -no_auto_start from werp_conn 
command. 


DNS Reply Received—Received valid reply from 
DNS. 


DNS Error Received—Received error response from 
DNS. 


Open Error—Permanent error in FLAP_Connect 
call. 


Reopen Timer—Reopen timer expired. 


Reopen Limit—Limit of reopen attempts reached. 


FLAP Conn Opened—FLAP connection open 
completed. 


FLAP Conn Closed—FLAP connection closed by 
script processor. 
=> stop_conn with no users—werp_stop_conn 
issued and no members were using the script 
processor connection. 
stop_conn with users—werp_stop_conn issued 
but members were using the script processor 
connection. 
stop_conn —abort—werp_stop_conn issued with 
-abort flag. 
start_conn—werp_start_conn issued. 
start_conn —dns—werp_start_conn issued with - 
dns flag or a host name had not yet been 
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ee resolved. 


fsm_transitions Displays the valid events for each state and shows the 
new state entered. 


fsm_hist Displays a histogram of the duration that a connection 
spent in each state. 


Clears the state transition sats 





o/ AOL Back-End Server Configuration 


werp_add_back_end {<snac— Defines the routing for a SNAC type / foodgroup and 

Eee rere Ore) eae foodgroup version to an AOL back-end server. The 

version> <tih-queue> [- : . 

forward] <queue-name> —-direct | queue name given Is a TIH queue as the WERP does 

berp -to_berp <queue-name> - its communicating with back-ends by forwarding 

pog iappl_id <id> -func_id through the BERP. A set of these commands is 

<id> <rr-class> ~round-robin | normally placed in a separate file that is sourced from 
the werp_post.tcl file. This file should be kept separate 
from the one used to define script processors. An 
updated version of the file can be sourced at any time 
from the control port. A werp_add_back_end for 
existing mappings is ignored. If a new queue is given 
for an existing snac-type or foodgroup, the queue is 
updated. Entries not contained in the new file are 
preserved and must be removed with 
werp_del_back_end. The -to_berp special sending 
method causes the message to be sent directly to the 
BERP (through the member's TIH address). This is 
used for SUS messages to the BERP. 


werp_del_back_end {<snac-— Delete a routing entry for SNAC type / foodgroup and 
werp_show_back_end [- Display routing entries currently defined if -snac_type 
nee types] Phtet] is given or assumed by default. If -hist is given, a 


histogram of how long each back-end took to respond 
to SNACs sent toit by the WERP is included. 








Technical Note: A delivery option exists for sending SNACs to back-end servers by 
attaching a POG header to the SNAC and sending it to a POG. The format for the 
werp_add_back_end command is: 





werp_add_back_end { <snac-type> | <foodgroup> } 

<version> <queue> 
[-=forward | =direct | =toberp | —pog] 
[-appl_id <id> -func_id <id>] 

where 

<snac-type> gives the SNAC type name 

<foodgroup> gives the SNAC foodgroup name 

<version> gives the SNAC foodgroup version 
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<queue> is the name forwarding to the back-end 
-forward causes message to forwarded to server 
-direct causes message to sent to server 

-to_berp causes message to sent to BERP 

-pog causes message to sent to a POG 


-appl_id <id> gives the application ID 
-func_id <id> gives the function ID 


The -appl_id and -func_id options are required when using the -pog option, but must 
be omitted for the other routing methods. 


3.6 Cached Scripts Configuration 


WERP caches script sets that ser used to minimize requests to File Station. The cache 
is maintained in order of most recent usage; if script sets are to be deleted, they are 
removed from the end of list. 


Script sets may also be removed from the cache via control port commands or from 
invalidation messages received from File Station as the script sets are updated there. 


Command/Parameter Default Comment 


RP_SCRIPT_SET_CACHE 268,435, | Sets the upper limit for the memory usage 
: 456 (256 | for cached scripts. The memory checking is 
MBytes) | not precise and may exceed the given 
value by a few KBytes. 
werp_show_script [<script— If no arguments are given, the names, sizes, 
Sete Hene? avrer=eutee Stent and date/time info for the cached script sets 


1 > ' : : 
eee are displayed. If a single script set name is 




















given, the view rule subsets and text 
languages of the individual scripts within 
the set are shown. Giving a script set name, 
view rule (name of numeric ID), and text 
language name causes the actual script to be 
shows. 


werp_del_script <script—-set— aa Removes a script set from WERP's cache. 


name> 





Ignored if script set is not present. 


3.9 Configuration and Caching of Data Station Classes 


Multiple file station classes can be configured which allows a test file station setup to be 
created that is used for testers while normal users reference a production class. When a 
request is received, WERP first determines which file station class is to be used in 
responding to the request by scanning the list of classes in the order of definition and 
evaluating a view rule to determine if that member is allowed to use that class. 


The search stops as soon as an allowed class is found. For normal operation, the 
production file station class is defined last with a view rule of "all." 


WERP maintains separate caches for each file station class with the following features: 
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e Two time limits for cached entries can be defined on a per-class basis. These 
are a "check" time limit and an "expires" time limit. When a script set is 
selected, WERP compares the age of set (based one when it last loaded the set). 
If the age of the script exceeds the "expiration" time, the script set is deleted 
from cache and a fresh copy is requested from the file station. If the script age 
is less than the "expires" time, but exceeds the "check" time, the cached script is 
used for the request, but WERP sends a CHECK request to the file station to see 
if the script has changed. If it has, then WERP will remove it from its cache. 
Otherwise, the "start" time is reset in WERP"s cache. 

e A file station class can be defined as non-caching. WERP still keeps the loaded 
scripts in a cache so that they can be viewed using control port commands, but 
each request for a script set causes a fresh copy to be requested from the file 
station. 

e Acache memory limit can be configured for each file station class. As new 
script sets are loaded, the least recently used script sets are removed until the 
cache size goes below the given size. 


File station classes and their options are defined with the following command: 


Command/Parameter Default Comment 
werp_add_file_station 

<fs-class> 
Pew <viewsule>) evr "al | 
[tte <tt>] no checking Le 
La <> fnolimit | 


[-cache <limit> |] WERP_SCRI ET_ 
ae weet <fs-class> is the File Station class 
non_cachi 
name 

-vr <view_rule> gives a view rule 
for use of this i/f 

-ttc <ttc> gives max time before 
checking script 

-ttl <ttl> gives max time for 
using cached script 

-cache <limit> is the size limit 
for caching scripts 

-non_caching causes a fresh 
load for each request 























Although file stations are configured to send invalidate requests to servers which use 
them, it is possible for these messages to be lost. The "check" and "expires" timers 
provide a check against these lost messages. 


3.10 QMI, Big FLAP, and Script Processors 


Big FLAP and QMI can be used for talking between WERP and script processors. The 
specific communication mode is given on a per-script-processor-connection basis using 
the commands: 


Command/Parameter Comment 
werp_add_class <class> { where <conn-entry-list> is one or more of the following 
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<conn-entry-list> } 


werp_link <conn-id> <queue- 
name> 

[-vr 
<view-rule>] 

[-auto_start | - 
no_auto_start] 

[-fg_ver 
<werp-fg-ver>] 
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commands: 


werp_conn <conn-id> <host> <port> 
<view-rule>] 
| -no_auto_start] 
<werp-fg-ver>] 
-no_big_flap] 


<conn-id> indicates the ID of the connection 

<host> is the host name or IP address 

<port> gives the port number 

<queue-name> gives QMI queue name of script 

processor 

-vr <view-rule> is used to restrict use of connection 

given view-rule 

can be name or ID 

-auto_start starts the connection after load (default) 

-no_auto_start prevents conn from starting after load 
<werp-fg-ver> gives version of WERP SNACs to use 
-big_flap says that Big FLAP is supported (max limit 

of 2Meg currently on big flap messaging) 
-no_big_flap says it is not supported (no messages > 

64K) 





The choice of a werp_conn or a werp_link statement determines whether 
communication takes place over FLAP (werp_conn) or QMI (werp_link). 
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